home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / tcl / workshop / tcl93pr1.lha / tcl93-proceedings2 / futures / session4 < prev   
Text File  |  1993-06-14  |  10KB  |  233 lines
  1. Article 4747 of comp.lang.tcl:
  2. Path: chemabs!malgudi.oar.net!caen!math.ohio-state.edu!howland.reston.ans.net!agate!ygdrasil.CS.Berkeley.EDU!faustus
  3. From: faustus@ygdrasil.CS.Berkeley.EDU (Wayne A. Christopher)
  4. Newsgroups: comp.lang.tcl
  5. Subject: Tcl Future Directions Session #4 Notes
  6. Date: 13 Jun 1993 17:55:31 GMT
  7. Organization: University of California, Berkeley
  8. Lines: 219
  9. Message-ID: <1vfpmj$aeb@agate.berkeley.edu>
  10. NNTP-Posting-Host: ygdrasil.cs.berkeley.edu
  11.  
  12. These are the notes from the last "future directions" session at the
  13. Tcl/Tk conference at Berkeley, June 10-11 1993.  Other Berkeley people
  14. have been posting (or will post) notes for the other three sessions.
  15. The main focus of this last session was the Tk binding mechanism.
  16.  
  17.     Tcl Future Directions Session #4, Friday June 11 3:15-5:00
  18.     ----------------------------------------------------------
  19.     Notes taken by Wayne Christopher.
  20.  
  21. Tcl/Wool
  22. --------
  23.  
  24. The first speaker in this session was Philippe Kaplan of Bull
  25. (France).  He discussed the relationship between Tcl and other
  26. extension languages, in particular Wool.  He mentioned a system called
  27. WTK v2, which is an integration of Wool, Tcl, and Tk.  Some people
  28. made comments about the difficulty of supporting multiple extension
  29. languages in one system.
  30.  
  31. Improving the Tk Binding Mechanism
  32. ----------------------------------
  33.  
  34. John Ousterhout then led a discussion of the problems with the current
  35. binding mechanism, and discussed a proposed solution.  The following
  36. outline is based on his notes.  Lines tagged with a - are not part of
  37. the official handout.
  38.  
  39. 1. Overview
  40.     Problem:
  41.     * Hard to combine independently-developed bindings for widgets
  42.     Solution:
  43.     * Allow more than one binding to trigger for widget
  44.     * Add tag-like mechanism for specifying related groups
  45.       groups of bindings
  46.     * Provide control over order of execution of bindings
  47.  
  48. 2. Current bindings
  49.     Three kinds of bindings:
  50.     * Widget-specific bindings:  bind .a.b.c ...
  51.     * Class bindings:  bind Button ...
  52.     * "All" bindings:  bind all ...
  53.     A single binding triggers for each event
  54.     * Widget-specific has priority over class
  55.     * Class has priority over "all"
  56.     * Within type, "most specific" binding wins:
  57.         <Escape> beats <KeyPress>
  58.         <Control-B1-Motion> beats <Motion>
  59.     Class bindings used for default widget behavior
  60.     Widget-specific bindings used for overriding, extending default
  61.     behavior
  62.  
  63. 3. Problems with current approach
  64.     Bindings don't compose gracefully
  65.     Example: add additional widget-specific actions to <Enter> for
  66.     buttons
  67.     * bind .b <Enter> foo
  68.     * Replaces normal class binding for <Enter>, breaks normal
  69.       button behavior
  70.     * Current solution:
  71.         bind .b <Enter> "[bind Button <Enter>]; foo"
  72.     * But what if class binding changes to <Any-Enter>?
  73.     "All" bindings don't really work very well
  74.     - Usually events don't get past widget and class bindings
  75.  
  76. 4. Proposed solution
  77.     (based on suggestion by Michael Halle)
  78.     Let multiple bindings trigger on a single event
  79.     * First find and trigger one widget-specific binding
  80.     * Then trigger one class binding
  81.     * Then trigger one "all" binding
  82.     Add support for a break command to skip remaining bindings
  83.     Only one binding can trigger within a group
  84.     Disadvantage: not backward compatible
  85.       - continue can also be used, in addition to break, to control the
  86.     sequence of binding triggers (I'm not clear on exactly what this
  87.     would do)
  88.       - What happens if a binding calls a proc, and the proc does a
  89.     break?  This will be an error, but one might want it to break
  90.     out of the binding sequence.
  91.       - When complex sets of libraries all want to set up their own
  92.     bindings, can they use break effectively?  Maybe this will cause
  93.     problems.
  94.       - A number of comments were made that suggest that the use of
  95.     break may be problematic.  Add a new break-like command and
  96.     TCL_ return status?  Needs more thought.
  97.     Provide new command to change binding tags for a widget
  98.     * Change widget's class for binding purposes
  99.         bind MyButton <Enter> ...
  100.         bind tags .b .b MyButton all
  101.         - Each of the arguments after "bind tags" is a binding
  102.           class, which will be searched in turn for matching
  103.           bindings.
  104.         - Many people made the point that it would be nicer to
  105.           have these classes in a single list, instead of as
  106.           separate arguments.
  107.         - It might be nice to specify a list of event types, for
  108.           which the list of tags are used.
  109.     * Add a new independent set of bindings
  110.         bind special ...
  111.         bind tags .b special .b Button all
  112.     * Replace all bindings for widget
  113.         bind tags .b special
  114.     * Make widget-specific bindings trigger after class bindings:
  115.         bind tags .b Button .b all
  116.     - If a list were used for the bindings rather than separate
  117.       arguments, one could use "bind tags .b" to enquire about the
  118.       list of binding tags, and "bind tags .b {}" to delete all
  119.       the bindings.
  120.     - If tags are available, maybe the "break" functionality isn't
  121.       necessary here.
  122.     - Maybe bindings should be able to explicitly manipulate the
  123.       list of other bindings that are going to be executed, or
  124.       change its order.  Maybe this is a bit much.
  125.     - Would it be useful to provide the same mechanism for class
  126.       bindings?
  127.     - Another, related idea -- all widgets have a bit of code that
  128.       is executed as a "startup script" when they are created.  This
  129.       code could set up the bindings appropriately.
  130.     - It would be useful to get default bindings in a more flexible
  131.       way.  If .b has no explicit bindings for <Event>, should ".b <Event>"
  132.       return "", or the default bindings?
  133.     - A possible concern is that if knowledgeable users try to modify
  134.       scripts -- for example if they have a 2-button mouse and the
  135.       author didn't think of that -- if the binding mechanism is too
  136.       complex they will break things.  (Is it true that bindings are
  137.       the most common things that users try to hack on?)
  138.     - Probably the tags mechanism isn't going to get used much.
  139.     - Tags are good for program structuring because they allow one to
  140.       group together sets of related behaviors.
  141.     - Can something be done with an array of bindings?  A widget can
  142.       just maintain an array like this and call each one in
  143.       succession.  This can be done without any changes to the current
  144.       mechanism.
  145.     - Problems with events going up widget hierarchies.  If there are
  146.       overlays (mostly transparent windows that were mentioned earlier in the
  147.       context of canvasses) will there be a problem forwarding events?
  148.     - Another thing for the wish list: a Tcl-level interface to XSendEvent
  149.  
  150. The overall consensus seemed to be that the proposed changes to the
  151. binding mechanism were good, but some details, such as the use of
  152. break, needed more thought.
  153.  
  154. Event Priorities
  155. ----------------
  156.  
  157. Brian Smith discussed a new scheme he had developed and recently
  158. posted to comp.lang.tcl for extending the event dispatching mechanism
  159. in Tk.  This was in the context of the multi-media real-time work he
  160. and Larry Rowe discussed earlier.
  161.  
  162. 1. Problems
  163.     When using "after", timer interval errors tend to accumulate.
  164.     Events may not happen close enough to the correct time.
  165.     With the current fixed priority scheme, there is not enough
  166.     flexibility
  167.     * Some RPC channels need tighter time bounds than others
  168.     * It is hard to to round-robin among different channels
  169. 2. Solution
  170.     Priority groups, e.g,
  171.     RPC -> high -> Tk -> low
  172.     All X events go into the Tk priority group
  173.     Events in the highest priority group are processed in the normal
  174.     order
  175.     (I don't think I can describe the system properly in more detail --
  176.     please refer to the recent posting, or maybe Brian can fill in the
  177.     details if there is interest)
  178.  
  179. 3. Event loops
  180.     The first step seems to be to separate the Tk event loop from
  181.     the rest of Tk, as much as possible, so that it can be used in
  182.     other extensions of Tcl that don't have X
  183.  
  184. Future Plans
  185. ------------
  186.  
  187. Larry Rowe conducted the final discussion of the conference.
  188.  
  189. 1. How to make Tcl/Tk more popular
  190.     More motif compatibility -- e.g., drag and drop
  191.     Mac/PC ports of Tk -- this seems the next big step.  There are
  192.     two ways to do this:
  193.     * Pay somebody to do it and then sell it
  194.     * Get a consortium to pay for a public domain effort, like the
  195.       X consortium.  This might cost between $200K and $300K
  196.     - It people have to pay for it, it will never get popular
  197.     - Some mention was made of Cayman's Galaxy system, which
  198.       provides a uniform API for Mac and Windows UI's (and Motif?)
  199.       We could either use their code, or do the same sort of thing
  200.     - A number of people said that they might be able to raise
  201.       some money for such a project -- the prospects look
  202.       encouraging.  The government doesn't seem to want to pay
  203.       for this, however
  204.     - It would help porting if Tk were restructured to hide the
  205.       X dependencies a bit.  It would also help if a "gadget"
  206.       approach were used, with only one window per hierarchy,
  207.       but this is not likely to happen soon
  208.  
  209. 2. The next workshop
  210.     Probably there will be one next year
  211.     Might be on the East Coast
  212.     Somebody needs to volunteer to organize it, but nobody seemed to
  213.     be eager to do this
  214.     Format questions:
  215.     * restricted to ~60 people or unrestricted, or a mixture
  216.     * include tutorials?  introductory, advanced?
  217.     * is 2 days okay, or should it be longer?  (probably 3 days if
  218.       tutorials, otherwise 2 days seem fine)
  219.     Would it make sense to put the Tcl conference under the Usenix
  220.     umbrella?  Some advantages to this but not likely to happen right away
  221.     Workstations should be available for demos, and for internet access
  222.     Work in progress sessions?
  223.     Clinic sessions ("Dr Ousterhout, my widget hurts when I do this...")
  224.  
  225. If anybody has any suggestions or wants to volunteer for anything,
  226. please send mail to Larry Rowe (larry@cs.Berkeley.EDU)
  227.  
  228. If anybody wants printed copies of the proceedings for $20, get in
  229. touch with Larry.  Also, Larry Virden has volunteered to organize
  230. on-line availability of the papers (stay tuned)
  231.  
  232.  
  233.